Match composite actions in step-level GitHub Actions recipes - #223

`PinGitHubActionsToSha` and friends were gated on `IsGitHubActionsWorkflow`,
so they only ever ran on `.github/workflows/*.{yml,yaml}` and silently skipped
composite actions, whose steps live in `action.yml` under `runs.steps`.

`IsGitHubActionDefinition` already matched those files, and `ChangeAction`,
`ChangeActionVersion` and `UpgradeOfficialGitHubActions` already OR'd the two
preconditions together. Extract that into
`GitHubActionsPreconditions.workflowOrActionDefinition()` and route every
step-level recipe through it, replacing the inline copies and the private
duplicate in `UpgradeOfficialGitHubActions`.

Most matchers needed no change: the `setup-*` recipes use relative
`..steps[?(@.uses =~ ..)]` paths and `ArtifactSecurity`/`TemplateInjection`
use `$..steps[*]`, both of which already reach `runs.steps`. `SetupJavaCaching`
was the exception, anchored at `$.jobs..steps`; `$..steps` is equivalent for
workflows, since nothing else there has `steps`.

Recipes that read workflow-only keys keep the narrower precondition, as
`action.yml` has no `on:`, `jobs:`, `runs-on:`, `permissions:` or `needs:`.

Also guard `UnpinnedDockerImages` against local Dockerfile builds. A Docker
container action's `runs.image` is often `Dockerfile` or `./path/Dockerfile`,
which has no digest to pin and would otherwise be flagged.

Replaces the `GitHubActionsPreconditions.workflowOrActionDefinition()` static
helper with a named recipe that ORs `IsGitHubActionsWorkflow` and
`IsGitHubActionDefinition`. A static method is only reachable from Java, so
declarative YAML recipes had no way to express "workflow or action definition"
as a precondition; a recipe can be referenced from both.

All 21 call sites now pass it to the `Preconditions.check(Recipe, ..)`
overload, which is recipe-aware, rather than handing over a bare visitor.